resolve: Mark items under exported ambiguous imports as exported #150491

petrochenkov · 2025-12-29T17:19:08Z

After #147984 one of the imports in an ambiguous import set becomes accessible under a deny-by-default deprecation lint.

So if it points to something, that something needs to be marked as exported, so its MIR is encoded into metadata, its symbol is not lost from object files, etc.
The added test shows an example.
This fixes around 10-20 crater regressions found in #149195 (comment).

Unblocks #149195.

rustbot · 2025-12-29T17:19:11Z

These commits modify tests/rustdoc-json.
rustdoc-json is a public (but unstable) interface.

Please ensure that if you've changed the output:

It's intentional.
The FORMAT_VERSION in src/librustdoc-json-types is bumped if necessary.

cc @aDotInTheVoid, @obi1kenobi

rustbot · 2025-12-29T17:19:13Z

r? @jackh726

rustbot has assigned @jackh726.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

petrochenkov · 2025-12-29T17:29:19Z

cc @obi1kenobi #149195 (comment)

From the cargo-semver-checks's point of view introducing a public name through an ambiguous reexport is clearly a breaking change, even if it technically can be allowed (and is allowed implicitly in dependencies).
Cases like that are actually reported by rustc using another lint called ambiguous_glob_reexports (regular, not future-compatibility).

Not marking items accessible through ambiguous imports as exported can cause errors like "missing optimized MIR" or linking errors, but I'm not sure if it can cause ICEs.
Reporting errors like that instead of ambiguous_glob_imports would probably be okay for directly compiled crates because they already produce an error (the lint is deny-by-default), but is not so good for ambiguous glob imports in dependencies because unlike lints such errors cannot be capped and break all other crates depending on the crate using them.

obi1kenobi · 2025-12-29T18:03:54Z

Thanks for the tag. I read the contents of this PR and also the description at #147984 (comment) and I still have a few questions.

#147984 (comment) mentioned the desire to make both local and cross-crate ambiguous errors behave consistently, which makes sense to me. But is that change limited solely to improving errors only? Or is it possible that a Rust program that previously would have failed to compile now is able to compile without errors, even if some lints had to be allowed?

cargo-semver-checks currently treats ambiguity as "attempting to use either item is an error." I'm attempting to determine if that's ever not correct, including with lints, so we can raise the right diagnostic with full and accurate info.

Right now I'm worried that I don't know how to model the case of "one of the items is made available but it isn't defined which one".

petrochenkov · 2025-12-29T18:26:29Z

Right now I'm worried that I don't know how to model the case of "one of the items is made available but it isn't defined which one".

That's the main problem, the compiler cannot define it either - it depends on internal unstable details that we don't want to expose, like specific expansion and import resolution order.
Otherwise this wouldn't be an error or future error.

If this is reported as a deprecation lint and not an error, the specific compiler's choice can be visible from the the effective visibility tables - the chosen alternative will be marked as exported, and the other alternatives will not.

Or is it possible that a Rust program that previously would have failed to compile now is able to compile without errors, even if some lints had to be allowed?

It's a language change, not just diagnostics, more names appear in modules and they may cause more names to appear in other modules through imports, and may cause more name conflicts.

In case of glob conflicts new programs will be able to compile under deprecation lints, some programs that previously compiled will report deprecation lints and will stop compiling in the future, in corner cases some compiling programs even start reporting hard errors like in the examples from #147984 (comment).
It probably cannot make previously erroneous programs compile without deprecation lints.

petrochenkov · 2026-01-08T20:59:14Z

r? @yaahc
Apologies for reassigning one more PR to you, this is logically a part of #147984 which you reviewed.

petrochenkov · 2026-01-22T11:53:40Z

ping @yaahc, it's been 2 weeks

yaahc · 2026-01-26T20:19:00Z

Hey, sorry for the delay. I took a look at it and it looks fine to me but to be honest, I don't have any prior familiarity with rustc_resolve/src/effective_visibilities.rs. I haven't had to dig into it for the reference documentation work so far so this is my first time exploring it that I can recall.

I did my best to go through this and try to understand what it does. I'm going to try to summarize it as I understand the logic and, assuming my summary is effectively correct, consider this an approval for r=me, but if my summary has any clear misunderstandings in it please help me correct them before merging.

I'm starting with set_bindings_effective_visibilities because despite it's changes coming later in the diff its invoked before the changes in compute_effective_visibilities so those changes apply first in practice.

set_bindings_effective_visibilities seems to do two important operations, updating the import_effective_visibilities and updating the def_effective_visibilities. Before and after this change we always update the import_effective_visibilities, regardless of ambiguity. However, when there is ambiguity, we would previously bail out from further iteration through the chain of imports and would not update the effective visibilities of any of the imports deeper in that chain of imports. Assuming we encountered an ambiguity that wasn't set to warn, after bailing we'd also skip updating the def effective visibility because decl would still be pointing to the ambiguous import in the chain instead of the def behind the chain of imports.

compute_effective_visibilities then goes and updates the effective_visibilities struct in the resolver based on the import_effective_visibilities (this struct is initialized with the content of def_effective_visibilities, so it seems to be a unification of those two structs from the visitor). Prior to this change it would check if the import was ambiguous, if it wasn't it would propagate its effective visibility into the resolver's EffectiveVisibilties member, else if the import was ambiguous and re-exported it would add it to exported_ambiguities. Importantly, these actions were mutually exclusive before, the information about the import would either go into one struct or the other depending on ambiguity.

After this change, these updates are treated as orthogonal, If there is ambiguity on a re-exported import, that gets tracked as before, but now even if there is ambiguity the effective visibility information about that import still gets propagated into the resolver's effective_visibilities struct. The changes to set_bindings_effective_visibilities mean that we're not skipping any updates to either of the def_/import_ effective visibilities structs which then all gets propagated into the resolver's unified copy of effective visibilities regardless of ambiguities, while still tracking ambiguities on the side via exported_ambiguities.

To try to put it into simpler terms, it looks like previously we'd track only the effective visibility of non-ambiguous imports and defs, we'd separately track any ambiguous re-exports, but only the outermost import in the chain, nothing deeper was tracked if it was only reachable through the ambiguity. Now we ignore ambiguity completely for the purposes of tracking effective visibility while still separately tracking which of those imports is ambiguous. On the surface this looks like a nice simplification of existing logic.

Let me know if I got that all right.

Also, thank you for splitting the test out into an earlier commit so I could see the diff in the error before and after the change.

petrochenkov · 2026-01-26T21:02:34Z

Your comment summarizes the logic quite well.

I haven't had to dig into it for the reference documentation work so far

Yeah, the effective visibility tables are not supposed to have a direct effect on language, because they are not necessarily precise (they can conservatively mark things as more reexported/reachable).
They mostly drive lints, link-time visibility and rustdoc.

In particular, the impreciseness and conservativeness allows us to mark slightly more things as exported in this PR. E.g. technically we only need to export things if the ambiguous reexport eventually reaches the crate boundary, because locally it's usually an error rather than a lint. But in practice crate-local parts of the effvis tables are not used much, so we just avoid all the complexity by marking the whole chains reexported.

I think eventually, when all cases of ambiguous_glob_imports become errors (or at least when there are not differences between local and cross-crate cases), a similar logic will need to be reintroduced to make the effective visibility tables more precise again.

yaahc · 2026-01-26T21:05:37Z

@bors r+

rust-bors · 2026-01-26T21:05:39Z

📌 Commit 6ada0d2 has been approved by yaahc

It is now in the queue for this repository.

🌲 The tree is currently closed for pull requests below priority 1000. This pull request will be tested once the tree is reopened.

resolve: Mark items under exported ambiguous imports as exported After rust-lang#147984 one of the imports in an ambiguous import set becomes accessible under a deny-by-default deprecation lint. So if it points to something, that something needs to be marked as exported, so its MIR is encoded into metadata, its symbol is not lost from object files, etc. The added test shows an example. This fixes around 10-20 crater regressions found in rust-lang#149195 (comment). Unblocks rust-lang#149195.

matthiaskrgr · 2026-01-26T22:17:15Z

looks like a test failed in #151710 (comment)

matthiaskrgr · 2026-01-26T22:17:22Z

@bors r-

rust-bors · 2026-01-26T22:17:27Z

Commit 6ada0d2 has been unapproved.

rustbot · 2026-01-27T13:45:23Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

petrochenkov · 2026-01-27T13:46:13Z

Rebased.
@bors r=yaahc

rust-bors · 2026-01-27T13:46:17Z

📌 Commit 44e89f8 has been approved by yaahc

It is now in the queue for this repository.

resolve: Mark items under exported ambiguous imports as exported After #147984 one of the imports in an ambiguous import set becomes accessible under a deny-by-default deprecation lint. So if it points to something, that something needs to be marked as exported, so its MIR is encoded into metadata, its symbol is not lost from object files, etc. The added test shows an example. This fixes around 10-20 crater regressions found in #149195 (comment). Unblocks #149195.

resolve: Mark items under exported ambiguous imports as exported After rust-lang#147984 one of the imports in an ambiguous import set becomes accessible under a deny-by-default deprecation lint. So if it points to something, that something needs to be marked as exported, so its MIR is encoded into metadata, its symbol is not lost from object files, etc. The added test shows an example. This fixes around 10-20 crater regressions found in rust-lang#149195 (comment). Unblocks rust-lang#149195.

JonathanBrouwer · 2026-01-27T14:36:32Z

@bors retry
Yielding to enclosing rollup

rust-bors · 2026-01-27T14:36:35Z

❗ You can only retry pull requests that are approved and have a previously failed auto build.

Hint: There is currently a pending auto build on this PR. To cancel it, run @bors cancel.

JonathanBrouwer · 2026-01-27T14:38:12Z

@bors yield

rust-bors · 2026-01-27T14:38:16Z

Auto build cancelled. Cancelled workflows:

https://github.com/rust-lang/rust/actions/runs/21401201828

The next pull request likely to be tested is #151743.

…uwer Rollup of 4 pull requests Successful merges: - #150491 (resolve: Mark items under exported ambiguous imports as exported) - #151161 (std: move time implementations to `sys`) - #151694 (more `proc_macro` bridge cleanups) - #151711 (stdarch subtree update)

resolve: Mark items under exported ambiguous imports as exported After #147984 one of the imports in an ambiguous import set becomes accessible under a deny-by-default deprecation lint. So if it points to something, that something needs to be marked as exported, so its MIR is encoded into metadata, its symbol is not lost from object files, etc. The added test shows an example. This fixes around 10-20 crater regressions found in #149195 (comment). Unblocks #149195.

rust-log-analyzer · 2026-01-27T17:39:55Z

The job x86_64-gnu-aux failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

##[group]Runner Image Provisioner
Hosted Compute Agent
Version: 20260115.477
Commit: 4b342d620503cbe250a3154040964899ea7c9b00
Build Date: 2026-01-15T22:32:41Z
Worker ID: {7bd5ced1-4f46-44b1-abad-3eb6bffb273c}
Azure Region: westcentralus
##[endgroup]
##[group]Operating System
Ubuntu
24.04.3
LTS
---
REPOSITORY                                   TAG       IMAGE ID       CREATED      SIZE
ghcr.io/dependabot/dependabot-updater-core   latest    354d02aa29ac   8 days ago   783MB
=> Removing docker images...
Deleted Images:
untagged: ghcr.io/dependabot/dependabot-updater-core:latest
untagged: ghcr.io/dependabot/dependabot-updater-core@sha256:596da3f22bcbdff2c96fd7126001278022c834c1621c5efa2ad1a7794590636c
deleted: sha256:354d02aa29acf525570c732b6e006ecf138de6d63ca525d552eb4b24880ddc6c
deleted: sha256:8b7af0e426bc2cbeeacfd96b8354d3b80016991520977197e62090e47abaede8
deleted: sha256:cadf11ef1de7fdd5eab563757942353684047f09b212dc99d6ed48e8acf34d62
deleted: sha256:569b0caf9d5285db44ccd2629a3470139eea755be423a33a54d8a24cb3926bfa
deleted: sha256:f9dc5feb048d8f9fd43137e3998f59e9acfbd76c47a4e14984d109654119e282
---
Initialized empty Git repository in /checkout/obj/build/ct/diesel/.git/
fatal: Could not parse object '3db7c17c5b069656ed22750e84d6498c8ab5b81d'.
From https://github.com/diesel-rs/diesel
 * branch            3db7c17c5b069656ed22750e84d6498c8ab5b81d -> FETCH_HEAD
HEAD is now at 3db7c17 Merge pull request #4917 from LucaCappelletti94/allow_tables_to_appear_in_same_query-modules
    Updating crates.io index
     Locking 261 packages to latest compatible versions
      Adding cargo_metadata v0.19.2 (available: v0.23.1)
      Adding darling v0.21.3 (available: v0.23.0)
      Adding generic-array v0.14.7 (available: v0.14.9)
      Adding getrandom v0.2.17 (available: v0.3.4)
      Adding libsqlite3-sys v0.35.0 (available: v0.36.0)
      Adding sqlite-wasm-vfs v0.1.1 (available: v0.2.0)
      Adding sqlparser v0.59.0 (available: v0.60.0)
---
test query_builder::query_id::tests::queries_with_different_types_have_different_ids ... ok
test sqlite::connection::stmt::tests::check_out_of_bounds_bind_does_not_panic_on_drop ... ok
test sqlite::connection::sqlite_value::tests::can_convert_all_values ... ok
test sqlite::connection::tests::correctly_handle_empty_query ... ok
test sqlite::connection::row::tests::fun_with_row_iters ... ok
test sqlite::connection::tests::register_aggregate_function_returns_finalize_default_on_empty_set ... ok
test sqlite::connection::tests::database_serializes_and_deserializes_successfully ... ok
test sqlite::connection::tests::register_aggregate_function ... ok
test sqlite::connection::tests::register_aggregate_multiarg_function ... ok
test sqlite::connection::tests::register_custom_function ... ok
---
test diesel/src/expression_methods/global_expression_methods.rs - expression_methods::global_expression_methods::ExpressionMethods::not_between (line 422) ... ok
test diesel/src/expression_methods/global_expression_methods.rs - expression_methods::global_expression_methods::ExpressionMethods::ne_all (line 169) ... ok
test diesel/src/expression_methods/global_expression_methods.rs - expression_methods::global_expression_methods::NullableExpressionMethods::assume_not_null (line 644) ... ok
test diesel/src/expression_methods/global_expression_methods.rs - expression_methods::global_expression_methods::NullableExpressionMethods::nullable (line 599) - compile ... ok
test diesel/src/expression_methods/global_expression_methods.rs - expression_methods::global_expression_methods::NullableExpressionMethods::assume_not_null (line 671) ... ok
test diesel/src/expression_methods/global_expression_methods.rs - expression_methods::global_expression_methods::NullableExpressionMethods::assume_not_null (line 706) ... ok
test diesel/src/expression_methods/json_expression_methods.rs - expression_methods::json_expression_methods::AnyJsonExpressionMethods::retrieve_as_text (line 18) ... ok
test diesel/src/expression_methods/text_expression_methods.rs - expression_methods::text_expression_methods::TextExpressionMethods::like (line 74) ... ok
test diesel/src/expression_methods/text_expression_methods.rs - expression_methods::text_expression_methods::TextExpressionMethods::concat (line 14) ... ok
test diesel/src/expression_methods/text_expression_methods.rs - expression_methods::text_expression_methods::TextExpressionMethods::not_like (line 110) ... ok
test diesel/src/insertable.rs - insertable::Insertable::insert_into (line 41) ... ok
test diesel/src/lib.rs - helper_types::InnerJoinQuerySource (line 571) ... ok
---
test diesel/src/query_builder/functions.rs - query_builder::functions::update (line 25) ... ok
test diesel/src/query_builder/functions.rs - query_builder::functions::replace_into (line 497) ... ok
test diesel/src/query_builder/functions.rs - query_builder::functions::sql_query (line 551) ... ok
test diesel/src/query_builder/functions.rs - query_builder::functions::update (line 49) ... ok
test diesel/src/query_builder/has_query.rs - query_builder::has_query::HasQuery (line 56) ... ok
test diesel/src/query_builder/has_query.rs - query_builder::has_query::HasQuery (line 27) ... ok
test diesel/src/query_builder/insert_statement/mod.rs - query_builder::insert_statement::IncompleteInsertStatement<T,Op>::default_values (line 68) ... ok
test diesel/src/query_builder/insert_statement/mod.rs - query_builder::insert_statement::InsertStatement<T,U,Op>::returning (line 282) ... ok
test diesel/src/query_builder/mod.rs - query_builder::debug_query (line 394) ... ok
test diesel/src/query_builder/sql_query.rs - query_builder::sql_query::SqlQuery<Inner>::bind (line 47) ... ok
test diesel/src/query_builder/sql_query.rs - query_builder::sql_query::UncheckedBind<Query,Value,ST>::sql (line 234) ... ok
---
test diesel/src/sqlite/connection/mod.rs - sqlite::connection::SqliteConnection (line 96) - compile fail ... ok
test diesel/src/sqlite/connection/mod.rs - sqlite::connection::SqliteConnection::exclusive_transaction (line 354) ... ok
test diesel/src/sqlite/connection/mod.rs - sqlite::connection::SqliteConnection::immediate_transaction (line 325) ... ok
test diesel/src/sqlite/connection/mod.rs - sqlite::connection::SqliteConnection::register_collation (line 500) ... ok
test diesel/src/sqlite/expression/expression_methods.rs - sqlite::expression::expression_methods::SqliteAnyJsonExpressionMethods::retrieve_as_object_sqlite (line 107) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::json (line 24) ... ok
test diesel/src/sqlite/expression/expression_methods.rs - sqlite::expression::expression_methods::SqliteExpressionMethods::is (line 27) ... ok
test diesel/src/sqlite/expression/expression_methods.rs - sqlite::expression::expression_methods::SqliteExpressionMethods::is_not (line 62) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::json_array_0 (line 1385) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::json_array_1 (line 1385) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::json_array_2 (line 1385) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::json_array_length (line 109) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::json_array_length_with_path (line 176) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::json_error_position (line 253) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::json_group_array (line 931) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::json_group_array (line 967) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::json_group_object (line 1203) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::json_group_object (line 1230) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::json_object_0 (line 1094) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::json_object_1 (line 1094) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::json_object_2 (line 1094) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::json_patch (line 1627) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::json_pretty (line 342) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::json_pretty_with_indentation (line 472) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::json_quote (line 872) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::json_remove_0 (line 1489) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::json_remove_1 (line 1489) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::json_remove_2 (line 1489) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::json_type (line 755) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::json_type_with_path (line 802) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::json_valid (line 633) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::json_valid_with_flags (line 693) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::jsonb (line 65) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::jsonb_array_1 (line 1437) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::jsonb_array_0 (line 1437) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::jsonb_array_2 (line 1437) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::jsonb_group_array (line 1010) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::jsonb_group_object (line 1323) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::jsonb_group_object (line 1296) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::jsonb_group_array (line 1047) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::jsonb_object_0 (line 1146) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::jsonb_object_1 (line 1146) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::jsonb_patch (line 1707) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::jsonb_object_2 (line 1146) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::jsonb_remove_0 (line 1563) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::jsonb_remove_2 (line 1563) ... ok
test diesel/src/sqlite/expression/functions.rs - sqlite::expression::functions::jsonb_remove_1 (line 1563) ... ok
test diesel/src/upsert/on_conflict_extension.rs - upsert::on_conflict_extension::IncompleteOnConflict<Stmt,Target>::do_update (line 431) ... ok
test diesel/src/upsert/on_conflict_extension.rs - upsert::on_conflict_extension::IncompleteOnConflict<Stmt,Target>::do_update (line 383) ... ok
test diesel/src/upsert/on_conflict_extension.rs - upsert::on_conflict_extension::IncompleteOnConflict<Stmt,Target>::do_update (line 517) ... ok
test diesel/src/upsert/on_conflict_extension.rs - upsert::on_conflict_extension::IncompleteOnConflict<Stmt,Target>::do_update (line 475) ... ok
test diesel/src/upsert/on_conflict_extension.rs - upsert::on_conflict_extension::IncompleteOnConflict<Stmt,Target>::do_update (line 557) ... ok
---
    SUCCESS for generator 'f64 subnormal'. 4194305/4194305 passed in 100.702510952s
30/30 tests succeeded in 129.084474916s (30 passed, 0 failed, 0 stopped)
[TIMING:end] test::TestFloatParse { build_compiler: Compiler { stage: 2, host: x86_64-unknown-linux-gnu, forced_compiler: false }, target: x86_64-unknown-linux-gnu } -- 157.323
Build completed successfully in 0:51:54
# The build-std suite is off by default because it is uncommonly slow
# and memory-hungry.
##[group]Building bootstrap
    Finished `dev` profile [unoptimized] target(s) in 0.07s
##[endgroup]
warning: failed to connect to jobserver from environment variable `MAKEFLAGS=" -j4 --jobserver-auth=3,4"`: cannot open file descriptor 3 from the jobserver environment variable value: Bad file descriptor (os error 9)
  |
---
failures:

---- oneshot::recv_timeout_before_send stdout ----

thread 'oneshot::recv_timeout_before_send' (272902) panicked at library/std/tests/sync/oneshot.rs:140:14:
expected Ok(99)
stack backtrace:
   0: std::panicking::panic_handler
             at /checkout/library/std/src/panicking.rs:689:5
   1: core::panicking::panic_fmt
             at /checkout/library/core/src/panicking.rs:80:14
   2: oneshot::recv_timeout_before_send
             at library/std/tests/sync/oneshot.rs:140:14
   3: oneshot::recv_timeout_before_send::{closure#0}
             at library/std/tests/sync/oneshot.rs:130:30
   4: <{closure@library/std/tests/sync/oneshot.rs:130:1: 144:2} as std::ops::FnOnce<()>>::call_once - shim
             at /checkout/library/core/src/ops/function.rs:250:5
   5: <fn() -> std::result::Result<(), std::string::String> as std::ops::FnOnce<()>>::call_once - shim(fn() -> std::result::Result<(), std::string::String>)
             at /checkout/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
---- oneshot::recv_timeout_before_send stdout end ----
---

error: test failed, to rerun pass `-p std --test sync`
Bootstrap failed while executing `miri --stage 2 library/std -- --skip fs:: --skip net:: --skip process:: --skip sys::`
Build completed unsuccessfully in 0:13:21
make: *** [Makefile:61: check-aux] Error 1
  local time: Tue Jan 27 17:39:36 UTC 2026
  network time: Tue, 27 Jan 2026 17:39:36 GMT
##[error]Process completed with exit code 2.
##[group]Run echo "disk usage:"
echo "disk usage:"

rust-bors · 2026-01-27T17:40:24Z

💔 Test for c463ca4 failed: CI. Failed job:

auto - x86_64-gnu-aux (web logs, enhanced plaintext logs)

rustbot assigned jackh726 Dec 29, 2025

rustbot added the T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output. label Dec 29, 2025

petrochenkov mentioned this pull request Dec 30, 2025

resolve: Partially convert ambiguous_glob_imports lint into a hard error #149195

Open

This comment was marked as resolved.

Sign in to view

petrochenkov force-pushed the ambigeffvis branch from cc0952f to a6c32d3 Compare January 8, 2026 20:55

This comment has been minimized.

Sign in to view

rustbot assigned yaahc and unassigned jackh726 Jan 8, 2026

This comment was marked as resolved.

Sign in to view

petrochenkov force-pushed the ambigeffvis branch from a6c32d3 to 6ada0d2 Compare January 11, 2026 10:09

This comment has been minimized.

Sign in to view

rust-bors bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 26, 2026

JonathanBrouwer mentioned this pull request Jan 26, 2026

Rollup of 7 pull requests #151710

Closed

rust-bors bot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jan 26, 2026

petrochenkov added 2 commits January 27, 2026 15:53

tests: Reproduce the issue with missing MIR for ambiguous reexports

a8e9147

resolve: Mark items under ambigous imports as exported

44e89f8

petrochenkov force-pushed the ambigeffvis branch from 6ada0d2 to 44e89f8 Compare January 27, 2026 13:45

rust-bors bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jan 27, 2026

This comment has been minimized.

Sign in to view

JonathanBrouwer mentioned this pull request Jan 27, 2026

Rollup of 4 pull requests #151743

Closed

This comment has been minimized.

Sign in to view

rust-bors bot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jan 27, 2026

Uh oh!

resolve: Mark items under exported ambiguous imports as exported #150491

Are you sure you want to change the base?

resolve: Mark items under exported ambiguous imports as exported #150491

Conversation

petrochenkov commented Dec 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Dec 29, 2025

Uh oh!

rustbot commented Dec 29, 2025

Uh oh!

petrochenkov commented Dec 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

obi1kenobi commented Dec 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

petrochenkov commented Dec 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment was marked as resolved.

This comment was marked as resolved.

This comment has been minimized.

petrochenkov commented Jan 8, 2026

Uh oh!

This comment was marked as resolved.

This comment has been minimized.

petrochenkov commented Jan 22, 2026

Uh oh!

yaahc commented Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

petrochenkov commented Jan 26, 2026

Uh oh!

yaahc commented Jan 26, 2026

Uh oh!

rust-bors bot commented Jan 26, 2026

Uh oh!

matthiaskrgr commented Jan 26, 2026

Uh oh!

matthiaskrgr commented Jan 26, 2026

Uh oh!

rust-bors bot commented Jan 26, 2026

Uh oh!

rustbot commented Jan 27, 2026

Uh oh!

petrochenkov commented Jan 27, 2026

Uh oh!

rust-bors bot commented Jan 27, 2026

Uh oh!

This comment has been minimized.

JonathanBrouwer commented Jan 27, 2026

Uh oh!

rust-bors bot commented Jan 27, 2026

Uh oh!

JonathanBrouwer commented Jan 27, 2026

Uh oh!

rust-bors bot commented Jan 27, 2026

Uh oh!

This comment has been minimized.

rust-log-analyzer commented Jan 27, 2026

Uh oh!

rust-bors bot commented Jan 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

petrochenkov commented Dec 29, 2025 •

edited

Loading

petrochenkov commented Dec 29, 2025 •

edited

Loading

obi1kenobi commented Dec 29, 2025 •

edited

Loading

petrochenkov commented Dec 29, 2025 •

edited

Loading

yaahc commented Jan 26, 2026 •

edited

Loading